Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-025.txt

Text File | 1992-11-18 | 43.3 KB | 1,239 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 20 Mar 92       Volume 1 : Issue 25

Today's Topics:

    THINK C 5.0
    Programming in more than one language
    Dropping Aliases on Applications
    Searching though a folder within the system folder
    Hellcats of the Pacific and Fast Graphics
    Think C 4.0 Debugger and System 7
    Asynchronious Sound Recording
    Temporary file name suggestion
    PICT <-> Raw
    Detecting color hardware
    Floating point registers contents to main memory?
    TN #120 and Non-32 Bit QD
    NBP LookUp Problem


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Michael W. Gilbert)
Subject: THINK C 5.0
Organization: Syracuse University, Syracuse, NY
Date: Sat, 15 Feb 92 17:42:41 EST

I'm sure that this has been discussed to some extent, but I haven't
been able to keep up with this group over the past few months.

With the upgrade to THINK C 5.0, has the language come more into step
with the C++ "standard"?  Is it worth the $70 (or whatever) for me
to upgrade from 4.0 to 5.0 so that I can use this instead of
Turbo C++ for a class I'm taking?

Thanks!  e-mail responses, please.

/-----------------------------------------------------------------------------\
| Mike W. Gilbert          | Quick to Judge, Quick to Anger, Slow to          |
| Software Engineer        |   Understand, Ignorance and Prejudice, and Fear, |
| GE O&RSD, Syracuse, NY   |   walk hand-in-hand."     Peart, 1981            |
\-----------------------------------------------------------------------------/



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  THINK C 5.0
Date: 17 Feb 92 05:46:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Michael W. Gilbert) writes:
>
> I'm sure that this has been discussed to some extent, but I haven't
> been able to keep up with this group over the past few months.
>
> With the upgrade to THINK C 5.0, has the language come more into step
> with the C++ "standard"?  Is it worth the $70 (or whatever) for me
> to upgrade from 4.0 to 5.0 so that I can use this instead of
> Turbo C++ for a class I'm taking?

The Think C 5.0 object extensions don't fully conform to the current C++
standard. However I would gladly pay $70 for a nice C development environment
upgrade that works fine on a portable!

Kent Sandvik
- --
speaking on behalf of all those hackers who have died of a caffein overdose



---------------------------

From: [e-mail] (Jay D Thomas)
Subject: Programming in more than one language
Date: 16 Feb 92 05:52:21 GMT
Organization: University of New Hampshire  -  Durham, NH

In a Macintosh environment, is it possible to write a program in more than one
language?  In other words you wrote a free standing set of subroutines
in one language, compiled them, and then load them from another language
in order to call them?  Is there some kind of standard format that
creators of compilers are encouraged to use so that they are compatible
with each other?



- -------------------------

From: [e-mail] (Michael Peirce)
Subject:  Programming in more than one language
Date: 16 Feb 92 23:40:59 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jay D Thomas) writes:
> In a Macintosh environment, is it possible to write a program in more than one
> language?  In other words you wrote a free standing set of subroutines
> in one language, compiled them, and then load them from another language
> in order to call them?  Is there some kind of standard format that
> creators of compilers are encouraged to use so that they are compatible
> with each other?

Sure.  MPW linker will link any of a number of languages together
into a single program.  I very often link MPW Pascal and MPW C together.
Other options include Fortran and Modula 2.  There are others.

Calling between MPW C and MPW Pascal is easy.  C provides a "pascal"
keyword that is used to indicate that a given function should us Pascal
calling conventions.  Likewise, Pascal provides a way to do the same
thing for C called from Pascal.  Toolbox calls always use Pascal calling
conventions (though there are a couple of hidden jems that use C calling
conventions (see the transition queue stuff in AppleTalk for example)).

The THINK environments (THINK C and THINK Pascal) can't directly use
code from each other, but you can bring MPW objects (.o files) into a
Think project by running it through a converter.

--  Michael Peirce         --   [e-mail]
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California USA 95117
--           & Consulting  --   voice: [phone] fax: [phone]
--                         --   AppleLink: peirce & America Online: AFC Peirce



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  Programming in more than one language
Date: 17 Feb 92 03:59:03 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>
>The THINK environments (THINK C and THINK Pascal) can't directly use
>code from each other, but you can bring MPW objects (.o files) into a
>Think project by running it through a converter.

For the record, THINK Pascal can load both THINK C libraries and .O files
without an external converter. THINK Pascal produces .O-format files as
libraries, so a THINK Pascal-produced library can be loaded into THINK C
using oconv (the converter supplied with THINK C).

R.

--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Programming in more than one language
Date: 17 Feb 92 03:05:34 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jay D Thomas) writes:
>
> In a Macintosh environment, is it possible to write a program in more than one
> language?  In other words you wrote a free standing set of subroutines
> in one language, compiled them, and then load them from another language
> in order to call them?  Is there some kind of standard format that
> creators of compilers are encouraged to use so that they are compatible
> with each other?

Yes, the object file format is the key to inter-language linking. MPW has such
features (i.e. linker that resolves OMF files), and this is one of the reasons
people use MPW instead of Think (I had to think of at least one reason :-) ).

Otherwise Apple Events and the Object library will make it possible to have loosely
connected applications sending AE messages back and forth. This is the future model
Apple would like to have on user desktops, instead of huge 1400k applications with
every possible feature ever invented since the primitive man discovered the binary system.

Kent Sandvik
..not speaking for any company....



---------------------------

Subject: Dropping Aliases on Applications
From: [e-mail] (USENET News System)
Date: Sun, 16 Feb 1992 21:06:10 GMT
Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ


When a file is dropped on an application the finder resolves any
aliases BEFORE passing the file to the application in the AE message.
This stops you writing an application which deals with alises
themselves - witness all the trash utilities which delete the file the
alias refers to instead of the alias itself :-(.  Two questions:

1) Anybody know how to drop aliases without them being resolved?

2) If not, I think System 7.1 should have a SIZE bit which says an
application accepts aliases. Do you agree/disagree? Email and if
theres a call I'll summarize.

Thanks in advance,
            Nigel

--
- -
Dr Nigel Perry                    Email: [e-mail]
Department of Computer Science    Tel: [phone] ext 8900
Massey University                 Fax: [phone]
Palmerston North
New Zealand



- -------------------------

From: [e-mail] (Dan Walkowski)
Subject: >Dropping Aliases on Applications
Date: 19 Feb 92 16:15:48 GMT
Organization: University of Illinois at Urbana

Mr. Perry states:

When a file is dropped on an application the finder resolves any
aliases BEFORE passing the file to the application in the AE message.
This stops you writing an application which deals with alises
themselves - witness all the trash utilities which delete the file the
alias refers to instead of the alias itself :-(.  Two questions:


- --
I just wanted to point out that this is NOT the case with TrashMan, which
does not handle trash in this manner.  TrashMan deals with aliases correctly.

Dan Walkowski
--
Dan Walkowski
Univ. of Illinois
[e-mail]



---------------------------

From: [e-mail] (Scott Bronson)
Subject: Searching though a folder within the system folder
Date: 17 Feb 92 03:59:08 GMT

This seems like such an easy file system queston that it must be readily
apparent or in a FAQ somewhere.  However, it wasn't obvious to me, and
I couldn't find it in any csmp FAQs.  Help!

I want to keep a folder inside the system folder for the user to be able
to drop files.  I want to be able to PBCatSearch of PBFileSearch through
this folder (which will always have the same name) to find out the name,
file type, and file creator of all the files in there.

I haven't figured out how to get a directory ID of this folder.  I tried
getting the VRefNum of the system folder from SysEnvirons, then passing
this and the path ":Token Folder:" to PBCatSearch in the hopes that it
would return a directory ID.  No such luck.  NSVErr (No Such Volume).

Is there any standard or accepted way of doing this?  Does anyone have any
type of source code I can see to get it to work?  I'll even take PL/1 or
COBOL if you have it--just so long as it works!  I am REALLY frustrated
that such an easy problem is so hard for me to solve.

Thanks for any help you might be able to offer.  You just may save the life
of my poor Macintosh before I hurl it out the 10th floor window if it returns
another one of those $#&%! NSVErrs.  Seriously, thanks for any ideas at all.


   - Scott            +----------------: SCOTT BRONSON :-----------------+
+---------------------|  [e-mail]    [e-mail] |
| Programming in C is | 6850 El Colegio Road #234; Goleta, CA 93117-4300 |
| glissading indoors. +==================================================+
+=========================+



- -------------------------

From: [e-mail] (Grobbins)
Subject:  Searching though a folder within the system folder
Date: 18 Feb 92 04:31:13 GMT
Organization: DTS

In article <scott.698299148@mcl> [e-mail] (Scott Bronson) writes:
>I want to keep a folder inside the system folder for the user to be able
>to drop files.  I want to be able to PBCatSearch of PBFileSearch through
>this folder (which will always have the same name) to find out the name,
>file type, and file creator of all the files in there.

Code below.

>I haven't figured out how to get a directory ID of this folder.  I tried
>getting the VRefNum of the system folder from SysEnvirons, then passing
>this and the path ":Token Folder:" to PBCatSearch in the hopes that it
>would return a directory ID.  No such luck.  NSVErr (No Such Volume).

Gack.  SysEnvirons returns a WDRefNum, not a VRefNum, and you shouldn't
need to use partial pathnames at all.

>This seems like such an easy file system queston that it must be readily
>apparent or in a FAQ somewhere.

There are no easy file system questions.  There are, however, Tech Notes
nobody's ever seen...


Grobbins             [e-mail]

Usual disclaimers apply

- ------


PROGRAM GetSystemSubfolder;
USES Files, Folders;
CONST kMyFolderName = 'Special Place';
VAR
  sysVRefNum: INTEGER;
  sysDirID, myFolderDirID: LONGINT;
  retCode: OSErr;
  nameStr: Str255;
  myCInfoPBRec: CInfoPBRec;
  myHPB: HParamBlockRec;
  i: INTEGER;
BEGIN
  { find System folder -- with MPW or Think glue, this works
     under System 6 too }
  retCode := FindFolder(kOnSystemDisk, kSystemFolderType, FALSE,
    sysVRefNum, sysDirID);  { Inside Mac VI chapter 9 }

  IF retCode <> noErr THEN WriteLn('FindFolder returned error ', retCode)
  ELSE
    BEGIN
      { find dirID of my folder in the system folder }
      nameStr := kMyFolderName;
      WITH myCInfoPBRec DO
        BEGIN
          ioCompletion := NIL;
          ioNamePtr := @nameStr;
          ioVRefNum := sysVRefNum;
          ioDrDirID := sysDirID;
          ioFDirIndex := 0;
          ioFVersNum := 0; { MFS compatibility, per Tech Note 204 }
        END;
      retCode := PBGetCatInfoSync(@myCInfoPBRec); { Inside Mac IV chapter 19 }

      IF retCode <> noErr THEN WriteLn('PBGetCatInfo returned error', retCode)
      ELSE IF NOT BTst(myCInfoPBRec.ioFlAttrib, 4) THEN { Inside Mac IV-125 }
        WriteLn(kMyFolderName, ' is not a folder')
      ELSE
        BEGIN
          { index through all files in the folder; to index through all
            folders & files in the folder, use PBGetCatInfo instead of
            PBHGetFInfo }
          myFolderDirID := myCInfoPBRec.ioDrDirID;
          i := 0;
          REPEAT
            i := i + 1;
            nameStr := '';
            WITH myHPB DO
              BEGIN
                ioCompletion := NIL;
                ioNamePtr := @nameStr;
                ioVRefNum := sysVRefNum;
                ioDirID := myFolderDirID;
                ioFDirIndex := i;
              END;
            retCode := PBHGetFInfoSync(@myHPB);
            IF retCode = noErr THEN
              WITH myHPB DO
                WriteLn(nameStr, '  type:', ioFlFndrInfo.fdType);
          UNTIL retCode <> noErr;
        END;
    END
END.



- -------------------------

From: [e-mail] (Scott Bronson)
Subject:  Searching though a folder within the system folder
Date: 19 Feb 92 06:52:35 GMT

In <scott.698299148@mcl> [e-mail] (Scott Bronson) writes:

>I want to keep a folder inside the system folder for the user to be able
>to drop files.  I want to be able to PBCatSearch of PBFileSearch through
>this folder (which will always have the same name) to find out the name,
>file type, and file creator of all the files in there.

Sorry, I meant to say PBGetCatInfo or PBGetFileInfo.  I did use the
correct routines in my program--honest!  Just didn't remember the
correct names.  (duh..)

    - Scott



---------------------------

From: [e-mail] (Tng Tai Hou)
Subject: Hellcats of the Pacific and Fast Graphics
Date: 17 Feb 92 10:20:37 GMT
Organization: Institute of Systems Science, NUS, Singapore

I have just wowed my colleagues by running HotP full screen
on my old RasterOps 224 (1024x768x8bits, also 4bits and 1bit).
The speed of the polygon fills is fantastic. But even more
amazing is the full screen update. One has to see it to believe it.

Now this is more motivation for by passing Quickdraw and perhaps
even CopyBits, both of which I assume is what Eric Parker, the author,
chose to do. Now to diassemble the program ... Hope I am
not violating anything.

Tai Hou
Singapore



- -------------------------

From: [e-mail] (Steve Howell)
Subject:  Hellcats of the Pacific and Fast Graphics
Date: 17 Feb 92 12:41:48 GMT
Organization: University of Tasmania, Australia.

[e-mail] (Tng Tai Hou) writes:

>Now this is more motivation for by passing Quickdraw and perhaps
>even CopyBits, both of which I assume is what Eric Parker, the author,
>chose to do. Now to diassemble the program ... Hope I am
>not violating anything.


  Why don't you ask the author? He posts regularly on rec.mac.games and
seems perfectly willing to answer peoples questions.



- -------------------------

From: [e-mail] (Juri Munkki)
Subject:  Hellcats of the Pacific and Fast Graphics
Date: 17 Feb 92 13:59:46 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Tng Tai Hou) writes:
>Now this is more motivation for by passing Quickdraw and perhaps
>even CopyBits, both of which I assume is what Eric Parker, the author,
>chose to do. Now to diassemble the program ... Hope I am
>not violating anything.

I haven't looked at the code, but I've seen the game and I have a few
guesses as to how it works.

Hellcats doesn't do full screen updates. It only draws those areas that
have changed. This is something that MS Flight Simulator also used to
do and probably does even today. Video memory is so slow that it pays
to avoid unnecessary reads and writes to and from it.

The game probably keeps a vaguely region-like structure of what is
currently displayed on the screen. It can then create a similar
structure for what it wants to display as the next frame. The last
step is to draw the differences.

Only the drawing portion is bit-depth dependent, so its pretty easy
to support all bit depths. As long as the frames do not change too
much, the drawing speed remains good. The real trick in the drawing
routines is in optimizing the drawing code for horizontal line segments.
It's a lot like drawing a region.

Before you have the frame description, you have to scan-convert the
polygons. This is covered in many computer graphics books and has
really nothing to do with the Macintosh in specific. It's quite tricky
to write a fast scan converter that simultaneously draws multiple
polygons that have been sorted by priority (visibility).

Hellcats cheats a lot in the priority calculations. It probably does
backface culling and then uses a quick and dirty algorithm to sort the
remaining polygons. You can see the errors if you fly into an aircraft
carrier.

Still, I didn't think that this method would be fast enough for interesting
games, so I've never tried to write something like this. Apparently the
current Macs are fast enough or my guesses are totally wrong.

IMO, there's money to be made by writing a series of totally different
simulators (different planes and settings, some from reality, some fantasy
themes and a few science fiction games) instead of making more scenarios
for the current Hellcats simulator. Scenarios will not appeal to the wide
audience. New games are always more appealing.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



- -------------------------

From: [e-mail] (Steve Howell)
Subject:  Hellcats of the Pacific and Fast Graphics
Date: 18 Feb 92 05:44:02 GMT
Organization: University of Tasmania, Australia.

[e-mail] (Steve Howell) writes:

>[e-mail] (Tng Tai Hou) writes:


>  Why don't you ask the author? He posts regularly on rec.mac.games and
>seems perfectly willing to answer peoples questions.


  Oops.. of course, that should be "comp.sys.mac.games". Sorry...



---------------------------

From: [e-mail] (Benno Overeinder)
Subject: Think C 4.0 Debugger and System 7
Date: 17 Feb 92 11:17:45 GMT
Organization: FWI, University of Amsterdam

This may be a stupid question, but it will be clear I am new to Think C and
System 7.

I was reading the Bullseye tutorial in the Think C Guide and at the same
time playing with Think C 4.0. Running the Bullseye project with the source
level debugger on, resulted in a system error. The two windows of the
debugger appeared on the monitor, but none of the two was active, neither
any other window on the monitor was. It was not possible to activate any
window and the only solution was to reset my Mac. I have tried it several
times, mostly followed by the scenario described above, but once I read
an error message in the source level debugger saying that a bus error
appeared.

Does anyone recognize this? Thank you in advance,

  -- Benno
--
===========================================================================
 Benno Overeinder             Computer Systems Department
                      University of Amsterdam
 e-mail: [e-mail]         The Netherlands



- -------------------------

From: [e-mail] (Saltgirl)
Subject:  Think C 4.0 Debugger and System 7
Date: 18 Feb 92 19:36:00 GMT
Organization: University of Houston-Downtown

>I was reading the Bullseye tutorial in the Think C Guide and at the same
>time playing with Think C 4.0. Running the Bullseye project with the source
>level debugger on, resulted in a system error. The two windows of the
>debugger appeared on the monitor, but none of the two was active, neither
>any other window on the monitor was. It was not possible to activate any
>window and the only solution was to reset my Mac. I have tried it several
>times, mostly followed by the scenario described above, but once I read
>an error message in the source level debugger saying that a bus error
>appeared.
>
>Does anyone recognize this? Thank you in advance,
>

    Try turning Virtual Memory off if it is on....
    I have seen this same thing happen with projects of mine.
    It has to do with VM using bus errors (read the chapter on
    VM in IM-IV)

    Tina Femea
    [e-mail]




---------------------------

From: [e-mail] (Eshel Liran)
Subject: Asynchronious Sound Recording
Date: 17 Feb 92 13:02:25 GMT
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel

Is asynchronious sound recording possible ?
I want to be able to access the recorded information during the time it arrives
any ideas ? is it possible using the current sound driver ?
any sample codes avaliable ?

      Liran Eshel
  Bar-Ilan University,
   Ramat-Gan, ISRAEL
[e-mail]



- -------------------------

From: [e-mail] (Jim Reekes)
Subject:  Asynchronious Sound Recording
Date: 18 Feb 92 21:07:26 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eshel Liran) writes:
>
> Is asynchronious sound recording possible ?
> I want to be able to access the recorded information during the time it arrives
> any ideas ? is it possible using the current sound driver ?
> any sample codes avaliable ?

Yes, and it's all documented in Inside Mac VI - The Sound Manager.

The MacRecorder input driver is NOT asynchronious, but all Macs with
built-in sound input will.


- -----------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | All opinions expressed are mine, and
20525 Mariani Ave. MS: 81-EQ |  do not necessarily represent those
Cupertino, CA 95014          |  of my employer, Apple Computer Inc.



---------------------------

From: [e-mail] (Miika Asunta)
Subject: Temporary file name suggestion
Date: 17 Feb 92 17:17:41 GMT
Organization: Finnish Academic and Research Network Project - FUNET


Since it's easy to create conflicting names for temporary files
I suggest that every piece of code should use its four character
creator-code converted to a long integer as filename, and if there
is need for additional file names, the code would add _<number>
at the end of the name.

Example:
====================================================

Creator:        'ABCD'
Converted to long:    1094861636

Suggested Temporary filenamestring:     1094861636
Additional file names:            1094861636_0
                    1094861636_1
                    1094861636_2
                    1094861636_3
                    .
                    .
                    .
                    1094861636_n

====================================================

Some programs just use TickCount() to create Temporary file names,
I think this technique is more sophisticated and quarantees
unique filenames, anyway you need still check for conflicts, a user
might be running your code twice.

And last, the existence of a file can easily be checked with
FSMakeFSSpec() routine.

Miika Asunta
--
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&  Miika Asunta        &  [e-mail]  &  Double Bass Player   &
& tel. [phone]  &             &  Macintosh Programmer &
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Temporary file name suggestion
Date: 18 Feb 92 18:53:25 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Miika Asunta) writes:
>Since it's easy to create conflicting names for temporary files
>I suggest that every piece of code should use its four character
>creator-code converted to a long integer as filename, and if there
>is need for additional file names, the code would add _<number>
>at the end of the name.
>
>Example:
>====================================================
>
>Creator:        'ABCD'
>Converted to long:    1094861636
>
>Suggested Temporary filenamestring:     1094861636
>Additional file names:            1094861636_0
>                    1094861636_1
>                    1094861636_2
>                    1094861636_3
>                    .
>                    .
>                    .
>                    1094861636_n

I think no program should rely on *any* filenames not being used yet. *Any*
temporary file name you pick should be checked for uniqueness. And once you
have decided to do that, I see no need to agree on a particular filename
pattern between programmers (Your solution is unambiguous, but it's very hard
to find out for humans which filenames belong to which application. Personally,
I prefer to have temporary filenames of the form MyApp00014).

Matthias

- ---
Matthias Neeracher                                   [e-mail]
   "Your hurricane will be God's signature" -- Blue Aeroplanes



---------------------------

From: [e-mail]
Subject: PICT <-> Raw
Date: 17 Feb 92 19:14:57 GMT
Organization: Department of Computer Science, University of Toronto


Hi,
I'm in need of an application that will let me convert back and forth
between PICT format images and raw bit images. I want to make use of
Mac drawing programs on the one hand and write various image processing
routines of my own.
I know i'm being lazy (not writing up the two routines) but I'm sure
someone out there has done this before, and it seems a waste of time
to "reinvent the wheel".
I would greatly appreciate any kind of help ...

thanx in advance, eyal



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  PICT <-> Raw
Date: Mon, 17 Feb 92 20:30:40 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] writes:
>
>Hi,
>I'm in need of an application that will let me convert back and forth
>between PICT format images and raw bit images. I want to make use of
>Mac drawing programs on the one hand and write various image processing
>routines of my own.
>I know i'm being lazy (not writing up the two routines) but I'm sure
>someone out there has done this before, and it seems a waste of time
>to "reinvent the wheel".
>I would greatly appreciate any kind of help ...

If you can find an old version of Wayne Rasband's Image program, it saves in
a format which is near-raw (it has a header, but is otherwise raw).  Newer
versions save in TIFF.

It is rather big for image-conversion, though....
--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail]
Subject:  PICT <-> Raw
Date: 19 Feb 92 07:44:48 -0800
Organization: BC Systems Corporation

In article <[e-mail]>, [e-mail] writes:
>
> Hi,
> I'm in need of an application that will let me convert back and forth
> between PICT format images and raw bit images. I want to make use of
> Mac drawing programs on the one hand and write various image processing
> routines of my own.
> I know i'm being lazy (not writing up the two routines) but I'm sure
> someone out there has done this before, and it seems a waste of time
> to "reinvent the wheel".
> I would greatly appreciate any kind of help ...

Look at SuperPaint 3.0.  It has a function for "cutting to draw/paint" layers
which allows you to take a bitmapped image, cut to draw, then manuipulate it
like a PICT and vise versa.  Or you can take a bitmap and "TRACE" it to the
Draw layer.  I know SuperPaint 2.0 did this and I would assume that 3.0 does as
well (I haven't ordered my upgrade yet).

--
[e-mail]
Victoria, British Columbia, Canada




---------------------------

From: [e-mail] (Where there is darkness, light)
Subject: Detecting color hardware
Date: 18 Feb 92 01:35:10 GMT
Organization: Monkey Tree Computer Services

Can anyone tell me if there's an easy way for an application to tell if
a mac has color hardware?

The Inside Macintosh books show how to detect Color Quickdraw, but are very
vague when it comes to detecting the type of hardware.

Thanks,

Kris Bruland

--
Kriston M. Bruland          |    . .         . .      . . .      .       . .
[e-mail]  |    .   .     . .        .        . .       .   .
[e-mail]   |    .             .         .     .   .     .



- -------------------------

From: [e-mail] (Ben Haller)
Subject:  Detecting color hardware
Date: 18 Feb 92 10:36:07 GMT
Organization: Stick Software

In article <[e-mail]>
  [e-mail] (Where there is darkness, light) writes:
>Can anyone tell me if there's an easy way for an application to tell if
>a mac has color hardware?
>
>The Inside Macintosh books show how to detect Color Quickdraw, but are very
>vague when it comes to detecting the type of hardware.

If color QuickDraw is available, then you may use the color calls, and if
you're actually running in black and white, the colors will be translated
down to the 1-bit color table.  And of course if color QuickDraw is not
available, then you are guaranteed not to have any color hardware,
basically (there are a few monitors that use the original QuickDraw fgColor
and backColor, I think, but you really needn't worry about that unless you
want to...)  So you don't *have* to know whether you are in color or not,
you *can* switch based only on the availability of Color QuickDraw.
  Of course, since QuickDraw does such a poor job of doing color graphics
in 1-bit mode (using solid black or white instead of dither patterns, etc.)
usually it is best to figure out the bit depths of the various monitors on
the system, and change your drawing code to adapt to the environment.  For
this, use the GDevice manager, right next to Color QuickDraw in IM V.  In
many cases you need to loop over all attached monitors and draw separately
on each one, setting the clipping so you only draw to that monitor.  Then
your graphics will look optimal even if they bridge multiple monitors.
It's a bit of trouble, but not too bad if you design your code correctly.
And it looks really cool.
  As to your exact question (which I haven't yet answered because I suspect
it's not what you *really* meant), you can find out what hardware a machine
has by talking to each GDevice's driver.  The refNum of the driver is
stored inside the GDevice record.  If you get the book "Designing Cards
And Drivers for the Macintosh II and Macintosh SE" (I think that's the
title) it will tell you how to ask the driver what the name of the card is,
what bit depths it is capable of running in, etc.  However, *very* few
programs need to do this.  You should generally accept the environment
you're given, don't go switching bit depths and funky stuff like that.

-Ben Haller ([e-mail])
"What was the question? ... I was looking at the Big Sky..." - KT



- -------------------------

From: [e-mail] (Todd Green)
Subject:  Detecting color hardware
Organization: Indiana University
Date: Tue, 18 Feb 92 13:23:51 GMT


>In article <[e-mail]> writes:
>>
>>The Inside Macintosh books show how to detect Color Quickdraw, but are very
>>vague when it comes to detecting the type of hardware.
>
> [Ben's long description deleted]

Just in case you were interested in simply finding out whether or not
the machine was set to "Grays" or "Color" and the bit depth, here are
two simple routines that will do it for you.  (Of course you'll need
to call these multiple times, once for each monitor)

short GetDeviceDepth(GDHandle grafDevice)
{
    return((**(**grafDevice).gdPMap).pixelSize);
}

Boolean    IsMono(GDHandle grafDevice)
{
    return((!TestDeviceAttribute(grafDevice, gdDevType)));
}

Todd
--
Internet: [e-mail]
NeXTMail: [e-mail]
BitNet:   [e-mail]



---------------------------

Subject: Floating point registers contents to main memory?
From: [e-mail] (Russell Street)
Date: Tue, 18 Feb 1992 03:50:07 GMT
Organization: University of Auckland, New Zealand.

How do I move the contents of the floating point registers
(fp0 etc ) into a variable etc?

I thought
    fmove.x fp0, (a0)
would do it (with a0 pointing to a suitable storage space).
But when you go back the other way the result in fp0 not
correct.

I can not easily see what I should be doing from the
book of the 68000 family I have.



Thanks in advance...
- ------------------------------------------------------------
Russell Street ([e-mail])

Had you been alive at 3 am on the third of Autumn and switched
on your wireless you would have heard this:














- -------------------------

From: [e-mail] (Lincoln Stein)
Subject:  Floating point registers contents to main memory?
Date: 19 Feb 92 03:04:55 GMT
Organization: Massachusetts Institute of Technology

FMOVE.X FP0,(A0) will indeed move an extended format float into memory
at the address stored in A0.

FMOVE.X (A0),FP0 does the reverse.

You should be aware, if you are not already, that the extended format
float used by the 68881/68882 coprocessor is NOT the same as that used
by Apple's SANE.  Specifically, the 68881/2 format is a 12-byte
format, while the SANE format is 10 bytes.  If you are using a
high-level language as the front end of your floating point code, be
sure to tell the compiler to save storage for coprocessor-format
extendeds rather than SANE extendeds.  Reals and Doubles (4 and 8
bytes respectively) are always safe to use, since their 68881/2 and
SANE formats are the same.

I hope this helps.

- --------------------------------------------------------------------------
Lincoln Stein                Brigham & Women's Hospital, Boston
[e-mail]
- --------------------------------------------------------------------------




- -------------------------

Subject:  Floating point registers contents to main memory?
From: [e-mail] (Russell Street)
Date: Thu, 20 Feb 1992 00:50:50 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Lincoln Stein) writes:

>FMOVE.X FP0,(A0) will indeed move an extended format float into memory
>at the address stored in A0.

>FMOVE.X (A0),FP0 does the reverse.

My trouble was that I used "movea.l arrayOf12Chars, a0" instead
of "lea arrayOf12Chars, a0" so a0 was not pointing to anywhere
sensible!  After fixing that things work just great.


- ------------------------------------------------------------
Russell Street ([e-mail])
    "Thank you for your support -- I shall always wear it!"







---------------------------

From: [e-mail] (brad  morris)
Subject: TN #120 and Non-32 Bit QD
Date: 18 Feb 92 05:52:55 GMT
Organization: University of Chicago Computing Organizations

Well, I am using the code with some minor mods from tech note #120 to create
an off screen pixmap.  Seems to work fine on IIci (7.0, 6.0.5), IIsi (6.0.7),
and IIfx (7.0.1).  But on a IIcx (6.0.5), the copy bits seems to only be
copying one pixel of depth.  I am going to try to install the 32 bit QD init
and see if that helps, but I am at a loss as to why the code would do this.  A
quick check of IMV says that the copy bits routine should recognize what is
passed to it by the portVersion field.  And this is set the same way with or
without 32 bit QD, no?  It should be set by _OpenCPort, right?

What is the problem?  Anyone have a clue?  Could this be unrelated to 32
bit QD and simply be a weird init conflict or something?

And what is a quick way to find out if 32 bit QD is availible if using Think 5
and no Gestalt glue is availible?

Thanks all.

Brad Morris



- -------------------------

From: [e-mail] (brad  morris)
Subject:  TN #120 and Non-32 Bit QD
Date: 19 Feb 92 22:24:28 GMT
Organization: University of Chicago Computing Organizations

All right.  I have found out more.  First, it is a problem of not having
32 Bit QD.  When 32 Bit QD is installed on the Mac IIcx, everything is
fine.  Second, it is not a palette conversion problem, because I tried
to copy the palette to a clut and got the same result.  I am sure that
it is drawing the right bit map, and that the off screen port is a
color port and not a bit map.  And I am sure that the upper two bits
of the portVersion are set as they should be.  Furthermore, I looked
at the pict that was being drawn into the off screen bitmap on the
IIcx without 32 Bit QD and it was fine (the colors were there).
What I don't know about is what Apple's code in TN #120 does when it
sets up the GDevice.  The other real problem is that development is
done on a IIci that has 32 Bit QD in ROM, so there is no way to simulate
the problem on the development machine.

I have considered disabling color if 32 Bit QD is not available, but then
what is the point of creating my own offscreen pixmaps anyway.  I mean,
I should just scrap the thing and use a GWorld.

I am pretty desperate.  Does anyone out there know anything about this
stuff?

Pulling my hair out one by one...

Brad Morris



---------------------------

From: [e-mail] (William T. Douglass)
Subject: NBP LookUp Problem
Date: 18 Feb 92 19:28:31 GMT
Organization: The University of Texas at Austin, Austin, Texas

I have run into a problem with the following code fragment.  This is from a
standard module I wrote in Think C to perform NBP lookups. The routine receives
an EntityName (object, type and zone strings) and a buffer to store the list of
NVEs found matching that entity name.  It performs the NBP lookup call and
returns the # of objects found.

Other programs using this routine work fine, but this time around, the
NBPSetEntity call seems to go wacko.  The internal buffer used in creating the
NBP entity structure does not get set.  The NBPSetEntity call either is having
no effect, or is storing the entity structure in some strange location (not in
the internal LkUpBuf buffer.)

I am including the subroutine and the calling code in the hopes that someone
might see something (stupid or otherwise) that I am overlooking.  Perhaps
someone has run across this also; any help is appreciated.

Thx.

/******************** caller ********************/
EntityName    Ename;
char          MyBuffer[500];

memmove(&Ename.objStr, "\p*", 2);
memmove(&Ename.typeStr, "\pLaserWriter", 12);
memmove(&Ename.zoneStr, "\p*", 2);

/** call lookup procedure **/
i=NBPLookUpEntity(&Ename, (Ptr) &MyBuffer, sizeof(MyBuffer), 1);



/******************** NBP Lookup ***********************/
/** look up given entity name - return list in buffer **/
/** takes EntityName struct, buffer ptr, buffer size, & # to return **/
/** returns: >=0 means # entities in buffer           **/
/**                 <0 means error                    **/

int NBPLookUpEntity( EntityName *entName, Ptr buffer,
                           int bufferSize, int maxEnt )

/* EntityName    *entName   - name to lookup          */
/* Ptr           buffer     - return name in buffer   */
/* int           bufferSize - size of buffer          */
/* int           maxEnt     - max # of name to return */

{


        OSErr                   systemError=0;
        int                     i;
        char                    *LkUpBuf;
        MPPParamBlock   LookUpRec;

        /** build entity structure for lookup call   **/
        /** find all lw in specified zone      **/
        LkUpBuf = (char *) malloc(400);
        NBPSetEntity(LkUpBuf, (*entName).objStr, (*entName).typeStr,
(*entName).zoneStr);

        /** set up MPP record for confirm call **/
        LookUpRec.MPPentityPtr= (Ptr) LkUpBuf;
        LookUpRec.MPPretBuffPtr=buffer;        /* return buffer */
        LookUpRec.MPPretBuffSize=bufferSize;
        LookUpRec.MPPmaxToGet=maxEnt;            /* buffer can hold 5 matches */
        LookUpRec.MPPinterval=8;               /* about 1 sec (64 ticks) */
        LookUpRec.MPPcount=2;                  /* 2 tries */

        /** lookup all NVEs matching this EntityName  **/
        systemError=PLookupName(&LookUpRec,0); /* synch call */
        free(LkUpBuf);

        /** return neg. error code if error occurred **/
        /** else return # items in buffer **/
        if (systemError != noErr)
                return systemError;
        else
                return LookUpRec.MPPnumGotten;
}


--
Bill Douglass, TCADA

"I dreamed I was to take a test,
 in a Dairy Queen, on another planet."      L. Anderson



- -------------------------

From: [e-mail] (Eshel Liran)
Subject: NBP Lookup
Date: 19 Feb 92 12:40:03 GMT
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel

When I perform NBP Lookup the search is done using the EntityName, and I must
specify the size of the reception block.
What if i get more sockets then the maximum number which i specified ?
Is there a last flag, like in zone lookup ?
Is it possible to continue the lookup from where the last request stopped ?
Is it possible to perform a search according to the nodes IDs ?
Can I find out the total number of vissible sockets ? if so, how much
net-traffic does it cost me ?

      Liran Eshel
  Bar-Ilan University
   Ramat-Gan, ISRAEL
[e-mail]




---------------------------

End of C.S.M.P. Digest
**********************